👍 border-box breaks my brain much less than the default content-box rules.

Nice use of flex along with specified element widths to achieve your four-square layout.

Prefer to keep you script imports together. We should put this down by the script tag importing our index.js.

This is an extra closing div which breaks validation.

Be sure to validate your html when possible. The errors/warnings can help us write cleaner HTML. Even if our markup looks fine in the browser we're using, there's no guarantee invalid HTML will do so on other browsers, and it could even break in the same browser since there are no layout guarantees made for invalid HTML.

I like how this is set up to update the state value for the city, and then use the displayCity function, whose responsibility is to update the UI to reflect the current city state. Consider extracting these lines into a helper setCity(newCity) that you could also use in the reset handler.

updateCity expects to be registered as an event handler (it has a parameter to receive event details). Calling it here without event information leads to an error when trying to update the city in the UI. If we had a setCity helper as described above, we could use that instead, passing in the reset default city value.

Notice the repetition in these if/else if blocks. Code like this tends to be finicky, since humans tend to make easily overlooked typos that can be hard to track down. Consider a data structure and accompanying code similar to the following:

const tempColors = [
  [80, {ground: 'ground emojis', color: 'temp color'}],
  [70, {ground: 'ground emojis', color: 'temp color'}],
  [60, {ground: 'ground emojis', color: 'temp color'}],
  [50, {ground: 'ground emojis', color: 'temp color'}],
  [null, {ground: 'ground emojis', color: 'temp color'}],
];

const getSettingsForTemp = (temp) => {
  for (const [boundaryTemp, tempSettings] of tempColors) {
    if (boundaryTemp === null || temp > boundaryTemp) {
      return tempSettings;
    }
  }
};

Looking for repetition in the structure of our code and refactoring it to be captured in a data structure instead can make our code more flexible (behavior can be changed solely by changing data) while simplifying the code working with the data.

If we had this function, how could we simplify the logic here in displayEmojis?

Nice approach of setting a css class with the style details rather than setting the style properties in the code here itself.

The comments about splitting the function responsibility for temp/color would also apply to the sky function here. To think about how we could make this more data-driven, consider what changes we might make to this function if we had a data structure resembling:

const skySettings = {
  clouds: 'clouds emoji',
  sunshine: 'sunshine emoji',
  rain: 'rain emoji',
  snow: 'snow emoji',
  wind: 'wind emoji',
};